fix: answer the review of the best practices stack, update every dependency and regenerate the testing reference - #1564

… digest, and group the README badges (#1552)

Refs #1269. This adds the OpenSSF Scorecard workflow the issue asks for,
widens the supply-chain audit so the image that workflow's action runs
is judged, narrows the signature checks the site documents, and regroups
the README's badges. Two badges are still to come: the Scorecard badge
once the first run on main has published, which is read on scorecard.dev
since v2.5.0 only leaves a warning when the API refuses a run, and the
OpenSSF Best Practices badge once the project reaches passing on
bestpractices.dev, which waits for my registration there. The answers
for that form are prepared outside the repository, so nothing about them
lands on the site.

Rule 1 of `cmd/audit_supply_chain` held every `docker://` step to its
sha256 digest but never read a container action's `runs.image`:
`judgeAction` returned as soon as `runs.using` said `docker`.
`ossf/scorecard-action` is pinned to a commit and runs
`docker://ghcr.io/ossf/scorecard-action:v2.5.0`, a tag a push to that
namespace replaces, so the new workflow would have passed `make
check-supply-chain` without the audit ever reading its image. The audit
now reads `runs.image` wherever it opens an action, a pinned one from
the record or one of this repository, and tells it apart as the runner
does (`ActionManager` and `DockerUtil.IsDockerfile` in actions/runner):
the `docker://` scheme in any case names an image the runner pulls, a
value whose last path segment ends in `Dockerfile` or starts with
`Dockerfile.`, in any case, one it builds from the action's files at its
pin, and any other value one it refuses. An image named by its digest
passes, a Dockerfile passes, and an image named by a tag or by its name
alone is a finding, as are a value the runner refuses and metadata that
names no image. Reading the scheme in lower case alone would have let
`DOCKER://image:tag` pass as a Dockerfile while the runner pulled the
tag. The images a Dockerfile's FROM lines name are still not opened in
this layer, which its `doc.go` and `docs/development/cmd-utilities.md`
state; the top of the stack (#1564) opens them, in answer to this pull
request's review.

A new table in `declarations.go` can accept one image somebody else's
action names, under the one category it defines, `write-free-job`. Its
key is the action without its commit and the image without its tag, so a
bump that moves the tag keeps the declaration and the record's diff
shows the reviewer the new tag, while a bump that moves the image to
another repository leaves it excusing nothing. The category is checked
rather than trusted: every job that runs an accepted image must hold a
token that writes nothing but `id-token`, must run with `cache-mode:
none` and must read no secret, what the workflow hands down included,
since whatever a push to the tag puts there runs with that token, those
secrets and the runtime token the runner hands every container action.
The cache is held apart because `permissions:` does not reach it: on a
push or a schedule a job that sets no `cache-mode` can save an entry
that a later job on main or under a release tag restores and runs, such
as the pnpm `pages.yml` puts on its path or the layers the release's
image build reads with `cache-from: type=gha`. The table is held to the
tree like every other declaration table, a malformed key, an unknown
category, a missing reason and an entry that excuses nothing each being
a finding.

`scorecard.yml` runs on pushes to main and on Thursdays, with
`ossf/scorecard-action` v2.5.0 pinned by its commit and
`publish_results: true`, inside the restrictions the results API checks
before it accepts a run (no top-level env or defaults, no workflow-level
write, `id-token: write` in the Scorecard job alone, only approved
actions as that job's steps, and no key its parser does not know except
`cache-mode: none`, which the API accepts since scorecard-infra v0.2.0).
The workflow sets `cache-mode: none`. The analysis job holds `contents:
read` and `id-token: write` and checks nothing out, since on those
events the action reads the repository through GitHub's API. The SARIF
reaches code scanning from a second job that checks the tree out without
persisting a credential, so upload-sarif can fingerprint each alert, and
holds `security-events: write`, which can also dismiss code scanning
alerts and so is never held in the job the tag-named image runs in. That
job still uploads what the image wrote, and upload-sarif keeps each
run's tool name and `automationDetails.id`, which decide the analysis an
upload replaces, so it first refuses a SARIF whose runs are not named
Scorecard or whose id does not start with `supply-chain/`. The
`category` input is not set: upload-sarif applies it only to a run
without an `automationDetails`, and Scorecard writes one into every run.
The record gains the two new pins, `ossf/scorecard-action` and
`github/codeql-action/upload-sarif` at the commit the CodeQL workflow
already pins, and the security label now follows the workflow.

The decision recorded in the issue on 2026-10-14 stands as written: the
results API refuses a step that names the image by its digest. Its
`verify_workflow.go` reads a step's name as everything before its `@`,
so `docker://ghcr.io/ossf/scorecard-action:v2.5.0@sha256:...` is an
unapproved step and the API finds no Scorecard job at all, and it takes
the image directly only by a tag, which pins nothing the action's commit
does not. The declaration's reason says so.

The identity the analysis job can mint names `scorecard.yml` at
`refs/heads/main`, and that is the part a tag-named image could still
use. The npm, PyPI and nuget.org trusted publishers refuse it, each
naming `release.yml` and the `release` environment. The signature checks
the site documented did not: the security page's `cosign verify-blob` of
`checksums.txt` and `cosign verify` of the image, and the alternative
the binary install page offers, accepted any identity under this
repository's URL, so a certificate minted in the analysis job would have
passed them. They now name `release.yml`, at any `vX.Y.Z` tag for the
checksums and at the release the command names for the image, as
`install.sh`, `install.ps1` and `fetch-release-assets.sh` already did,
in English and Spanish. The MCP Registry is the one place this side
cannot narrow: its GitHub OIDC login grants `io.github.jmrplens/*` to a
token from any workflow of any of my repositories, so the analysis job
could publish a server version there. The reason states it, and it is a
cost of publishing the badge that the 2026-10-14 decision did not weigh.

The README's badges now sit in three rows inside one centered block,
each named by what a reader is checking: releases and packages, build
and quality, and directories; a security row opens with the Scorecard
badge once it has a score to show. The static platforms badge goes,
since the install section says the same, and so does the coverage badge,
since the quality gate beside it already fails on new code covered below
80% and CI holds the tree to 90%. npm and PyPI monthly downloads join
their version badges. Of the directories, the three whose badge the
listing serves stay (Glama's score, LobeHub's grade, MCP Toplist's
rank), the Cursor Directory label, which says only that a listing
exists, goes, and the hosted endpoint moves beside the packages. The
rows were never centered on GitHub: a `<p align="center">` closes before
the Markdown paragraph it wraps, and the LobeHub comment split the
directory row in two, both of which GitHub's rendering of the current
README shows. The install buttons keep their table.

How I tested it:

- The new tests in `cmd/audit_supply_chain/actions_test.go` failed
against a skeleton that compiled without the behaviour, and the cases
added for the scheme, the refused values and `cache-mode` failed against
the rule as it first stood: `DOCKER://ghcr.io/example/tool:v1` and
`Docker://alpine:3` drew no finding, `ghcr.io/example/tool:v1` and `'
Dockerfile '` none either, and no job was held to its `cache-mode`. All
pass with the change: `go test ./cmd/audit_supply_chain -count=1`. The
workflow-level `permissions`, `env` and `cache-mode` a job inherits are
each pinned by a case that fails when the audit reads the job alone.
- `make check-supply-chain` with the workflow and the record but without
the declaration fails on one line,
`ossf/scorecard-action@fa7117db83c52d787ae5a89f350999701505d78e/action.yaml:
runs.image docker://ghcr.io/ossf/scorecard-action:v2.5.0 is not pinned
to a sha256 image digest, and cmd/audit_supply_chain/declarations.go
gives no reason to accept it`; with the declaration and without
`cache-mode: none` it fails on `.github/workflows/scorecard.yml: job
analysis: step 0: uses:
ossf/scorecard-action@fa7117d runs
docker://ghcr.io/ossf/scorecard-action:v2.5.0, which
cmd/audit_supply_chain/declarations.go accepts by its tag only in a job
whose cache-mode is none, and this job's is unset, so a push or a
schedule can save to the Actions cache`; with both it passes.
- `cmd/audit_supply_chain`: 100% of statements, 1214 of 1214 conditions
under gobco, and `make coverage-mutants` with 843 killed, 0 lived, 0 not
covered and 0 timed out.
- `golangci-lint run --build-tags e2e ./cmd/audit_supply_chain/`, the
e2e compile (`go test -tags e2e -c -o /dev/null ./test/e2e/gitlab/...`)
and `GITLAB_MCP_TEST_SNAPSHOT_PARITY=deferred go test ./... -count=1` at
the head: all pass.
- The SARIF guard, run as the workflow writes it, passes Scorecard's own
SARIF and a two-run one, and refuses a run named CodeQL, a CodeQL
category, a run with no `automationDetails`, a numeric id, a file with
no runs, a file mixing a Scorecard run with another tool's, and a file
that is not JSON; shellcheck passes on it.
- actionlint 1.7.12, its latest release, reports one diagnostic on
`scorecard.yml`, `unexpected key "cache-mode" for "workflow" section`,
since the key is newer than its parser; GitHub documents it at the
workflow and the job level, and the results API lets exactly that key
through at the value `none`. The shellcheck it runs over the run block
reports nothing.
- The narrowed identities verify v3.3.0: `checksums.txt` against the
`release.yml` pattern, and the image on ghcr.io and Docker Hub against
`release.yml@refs/tags/v3.3.0`; a pattern naming another workflow is
refused.
- `markdownlint-cli2` on `README.md` and
`docs/development/cmd-utilities.md`, `node scripts/check-doc-links.mjs`,
the site's `i18n:check`, `facts:check`, `chips:check`, `version:check`
and `llms:check`, `make check-install-buttons`, `make check-md-tables`,
`make check-footprint`, `go run ./cmd/audit_doc_tool_names/ --check` and
`make check-em-dash`: all pass.
- The new README head rendered through GitHub's markdown API is one
centered block holding the three rows.

## On the rebased stack

I rebased the stack onto `main` at `8f339f4e8` on 27 October 2026. The
checks above ran on this layer before that rebase. On the rebased head,
`go build ./...`, `go vet ./...` and `go test ./... -count=1` pass with
the freshness comparisons deferred, as CI runs every layer below the
top, and every commit carries a `Signed-off-by` trailer. The committed
generated artifacts are regenerated once at the top of the stack, which
runs every gate over the combined tree.

## After the first CI round

SonarCloud found the literal `"image "` three times in
`judgeContainerImage` (S1192, critical): the key every finding about a
container action's image is reported once under. It is computed once at
the top of the function now, folded into the commit that added the rule;
no finding changes. On this layer's head `go test ./... -count=1` passes
with the freshness comparisons deferred, `cmd/audit_supply_chain` is at
100.0% of statements and 1214 of 1214 conditions, golangci-lint is
clean, and gremlins kills the 83 mutants of `actions.go` with none lived
or uncovered.

Milestone: 3.4.0.

---------

Signed-off-by: José M. Requena Plens <mail@jmrp.io>

…ition tier stack (#1571)

Refs #1280
Refs #1240

This is the top of the access level and edition tier stack. The four
layers below it, the access levels of #1280 and the three layers that
answer #1240, regenerate nothing under the freshness deferral, and this
layer regenerates once every committed artifact they move. It adds no
behavior of its own: one commit, the regeneration and the R-PATH
declaration that can only land with it.

The stack sits on `main` at `6c9066aef`, onto which I rebased it on 28
October 2026, layer by layer and in order. Every commit is signed and
carries a `Signed-off-by` trailer. The five files the layers add carry
the copyright and license header of #1563, written by `make
fix-file-headers` into the commit that adds each one. `main` took row
140 of the upstream register for gobco, so the two rows the layers add
are 141 and 142. The regeneration was made again on the rebased tree
rather than rebased.

## The regeneration

The layers changed the surface every generated artifact describes. The
access level parameters publish the levels each route accepts as integer
enums, the group access request approval reads the group and the
requester for a Minimal access approval, and the group, member, LDAP
link, group variable, issue, merge request, notification and project
parameters are tier tagged or described by tier.

- The tool snapshots of the individual surface and of the opaque,
compact and full meta schemas, which change on the tools those
parameters reach (`gitlab_access`, `gitlab_group`, `gitlab_member_role`
and `gitlab_project` on the opaque meta surface; `gitlab_admin`,
`gitlab_ci_variable`, `gitlab_issue` and `gitlab_user` as well on the
full one).
- The per-domain tool reference of the access, admin, ci-variable,
group, issue, member-role, merge-request, project and user groups, in
English and Spanish, the four llms files, the token footprint with the
README block it writes, and the testing reference, refreshed with
`-skip-coverage`.
- The action request record and the fine-grained table, which gain the
two optional reads of `access.approve_group` (`GET /groups/:id` and `GET
/groups/:id/members/:user_id`), and the fine-grained permissions
reference that prints them.
- The request inventory, recorded again on the whole unit suite with the
freshness checks on and merged: it gains those two reads and the
`new_epic` flag a group notification settings update now sends, and
nothing else moves.

The site stats, the brand assets, the manifests, the model evaluation
pages, the charts and the e2e coverage page regenerate unchanged, and a
second run of every generator over the committed result changes nothing.

## The R-PATH declaration

R-PATH reads the group the approval fetches as a `GroupDetail` the
package never publishes. I declared it beside the LDAP link listing's
existence probe, as a read the package makes for its own use: it is sent
only when `access.approve_group` is asked for `access_level` 5 on a
licensed session, reads `parent_id` alone to refuse the approval on a
subgroup before it is sent, and returns nothing of the answer. The
declaration lands here because only this commit's inventory holds the
read, and a declaration that answers nothing fails the audit.

## How I tested it

With the freshness checks on, on this head: `go test ./... -count=1`
passes (301 packages), `make analyze` passes every step (markdownlint,
which needs Node, and the file header check, which reads git's file
list, run locally on the same tree), every check the "Generated
artifacts" job of CI runs passes, among them `check-tool-reference`,
`check-llms`, `check-footprint`, `check-site-stats`,
`check-testing-docs`, `check-request-inventory`, `check-file-headers`,
`audit-1to1-paths`, `check-action-grants`,
`check-action-grants-derivation`, `audit-1to1-grants`,
`check-e2e-static` and `check-tenancy`, as do `check-server-json`,
`check-server-json-packages` and `check-openplugin`, `make check-dco`
passes on every commit of the stack, `make test-e2e-http` (780 tests, 8
of them skipped for want of Docker on the runner) and `make
test-e2e-stdio` (277 tests) pass, and the e2e packages compile. The site
passes `i18n:check`, `facts:check`, `chips:check`, `llms:check`, `build`
and `lint`, and `node scripts/check-doc-links.mjs` passes.

Against Docker GitLab 19.5.0 both complete runs passed with the skip
gate on, on this stack as it stood on `e3e09d290` before the rebase:
`make test-e2e-ce` ran 1321 tests with no failure and one skip, the
declared opt-in throttle probe; `make test-e2e-ee`, licensed, ran 1650
tests with no failure and no skip. The scenarios the layers added passed
on all three surfaces: on CE, the Minimal access approval refused on the
Free tier, a level the route does not grant refused with the request
still pending, an Owner-level project access token granted to an Owner's
token, and an issue created for two assignees keeping only the first; on
EE, the same refusal and token, the Minimal access approval refused on a
subgroup and granted on a licensed top-level group, and an instance
custom role on an Owner base refused. I did not run them again after the
rebase. What `main` brought in between does not reach those scenarios'
requests: the header lines are comments, the plain HTTP listener check
of #1561 is read only by an HTTP listener while the suite drives the
binary over stdio, the Orbit fixtures moved for the GitLab.com suite,
the Bitbucket fixture's image moved to 10.5 for the import coverage
behind its own profile, and of the dependency updates of #1564 the
binary links `golang.org/x/net`, whose IDNA package `internal/gitlab`
uses, and the gRPC modules of the OTLP exporter, which runs only with
telemetry turned on; the unit suite and both transport suites above run
on them.

## #1517

#1517 is open, and the maintainer has asked for changes before merging
it. This stack leaves to it everything it does or was asked to do: the
offset paging of the merge request diffs in `mr_review.changes_get`, the
page walk of the inline comment pre-check under RQB-013 with its check
of the position's SHAs against the merge request's `diff_refs`, and the
curated text, request declarations and test moves the review asked for;
nothing here touches `mrchanges`, `mrdiscussions`, `mrdraftnotes`,
`internal/toolutil/diff_position.go` or the tenancy register. Its unused
`order_by`, `sort`, `pagination` and `page_token` are #1530 and the
pre-check's `position_type` is #1531, both after #1517. Two hand-written
files are changed by both, in different blocks, so a rebase of either is
mechanical: `cmd/audit_1to1/internal/paths/sent_declarations.go`, where
this stack adds the access request probe to the existence probes and its
reason after the LDAP one while #1517 adds the merge request rows to the
position pre-check block and their reason, and the
`internal/tools/testdata/tools_meta.json` golden, where this stack
changes the `gitlab_access`, `gitlab_group`, `gitlab_member_role` and
`gitlab_project` entries and #1517 the `gitlab_mr_review` one. Both
change generated files: `tools_individual.json`,
`tools_meta_compact.json` and `tools_meta_full.json`,
`docs/development/request-inventory.json`,
`docs/development/action-requests.json`,
`internal/tools/actiongrants/table_gen.go`,
`docs/development/token-footprint.md` and
`site/src/data/token-footprint.json` with the README token block,
`docs/development/testing/testing.md`, `llms-full.txt`,
`llms-full-individual-tools.txt` and `llms-full-meta-tools.txt`.
Whichever of #1517 and this stack lands second regenerates those files
on top of the other, together with the `mr-review` tool reference, which
only #1517 changes and this stack regenerates unchanged.

Signed-off-by: José M. Requena Plens <mail@jmrp.io>

…lists end to end, and regenerate the stack's artifacts (#1575)

Refs #1165

This is the top of the first #1165 stack. It documents what the two
layers below added, the keyset half of the live GitLab record at schema
5 and the keyset half of R-PAGE that reads it, adds the end-to-end
scenario for the two service account token lists the first layer
changed, and regenerates once every committed artifact the stack moves,
which the layers below leave stale under the freshness deferral.

## The documentation

The contributor pages described schema 4 and an R-PAGE that raises no
keyset finding by design. In `docs/development/cmd-utilities.md`, the
`gen_api_live` section now says what the walk records for each route
(the paginator, the file and line quoted, the helpers it went through,
the parameters the next page is asked by, the feature flags with their
defaults), why a site says where GitLab can serve a keyset page rather
than that it does, and what `-check` refuses of that half. The R-PAGE
paragraph reads `keyset_routes` off the record's `keyset` field (53
routes, 39 of them offset too) rather than off the params (the 10 that
declare `per_page` without `page`), and a new paragraph describes the
keyset half: its four problems and their two grains, the
`keyset-not-followable` declarations, and the figures against the
committed record (202 actions offering `page_token`, 20 of them on
keyset routes that publish `next_page_token` and were seen following it,
182 on routes GitLab pages by offset alone, three lists declared).
`docs/development/request-paths.md` says the same in its R-PAGE bullet,
`static-analysis.md` and the repository map in a line each, and the
R-PAGE clause of `CLAUDE.md` names the rule and nothing more.

On the site, the output format page, in English and Spanish, says that
the two service account token lists, where GitLab refuses every keyset
request, no longer take `pagination` or `page_token`, refuse either
before sending anything and page with `page`, and that the lists still
answering a keyset request with 405 are the ones given an order GitLab
cannot page by keyset.

## The end-to-end scenario

Nothing drove either token list against a real GitLab with a keyset
argument, or with a sort order at all. Two scenarios in
`test/e2e/gitlab/common/keyset_pagination_test.go`,
`TestKeysetPagination_GroupServiceAccountTokens_PageByOffsetAlone` and
`TestKeysetPagination_ProjectServiceAccountTokens_PageByOffsetAlone`,
give a service account three tokens named so they sort in the order they
were made, and on every surface:

- send `pagination: "keyset"`, `page_token` and `order_by`, each held to
a refusal made before any request: the SDK's on the individual surface,
whose schema admits no property it does not list, execute's `Unknown
params` on the dynamic surface, and the meta dispatcher's `unknown
field`;
- follow the list one token a page by page number in `name_asc` order,
holding every page to carry no `next_page_token` and to name the next
page while `has_more` holds;
- read it whole in `name_desc` order, so an order GitLab ignored, which
leaves the tokens unsorted, reads as a failure rather than as a listing.

Both were red on the parent: driving the server built from `e3e09d290`,
the base of the stack before it was rebased onto `main`, against CE
19.5.0, every surface failed at the first argument (8 tests, 8
failures), because that server still sends `pagination=keyset` and
GitLab answers it, `405 {error: Keyset pagination is not yet available
for this type of request}`: `refused as tool_error, and the test
expected invalid_params` on the individual surface and `the error does
not mention "unknown field \"pagination\""` on the other two. That run
was of the scenarios' first version, whose dynamic case expected the
meta wording; the complete CE run of this stack showed that execute
refuses the argument earlier, with `Unknown params: pagination.` and the
list of valid params, and the dynamic case now expects that. With the
final version, the red run on the parent fails again on every surface:
GitLab answers `405 {error: Keyset pagination is not yet available for
this type of request}` for both `group.service_account_pat_list` and
`project.service_account_pat_list`. On the stack's head before the
rebases, the green run of the two scenarios passes.

## The regeneration

One commit, with the comparison checked:

- the tool snapshots of the individual surface and of the compact and
full meta schemas, which change on exactly the two token list tools and
the `gitlab_group` and `gitlab_project` schemas that carry them
(`pagination`, `page_token` and `order_by` gone, `sort` naming the eight
documented orders); the curated `tools_meta.json` does not change;
- the per-domain tool reference of the group and project groups, in
English and Spanish, the three llms files, the token footprint with the
README block it writes, and the testing reference, refreshed with
`-skip-coverage`;
- the request inventory, recorded again on the whole unit suite and
merged: the two token routes are no longer recorded sending `order_by`,
`page_token` or `pagination`, and the group one is now recorded sending
`page` and `per_page`.

The action request record and the fine-grained table, the site stats,
the brand assets, the manifests and the e2e coverage page regenerate
unchanged.

## How I tested it

The stack was written on `e3e09d290` and rebased twice: onto `main` at
`6c9066aef`, after the OpenSSF Best Practices stack, and onto `main` at
`56758fb71`, after the access level and edition tier stack (#1567 to
#1571). In this layer's two hand-written commits the first rebase
changed one place: `main` added rows to the pipe table of
`docs/development/static-analysis.md` and padded it again, so I took
`main`'s table, put this layer's sentence back into the `check-api-live`
row and ran `go run ./cmd/format_md_tables/`. The second changed nothing
in them: what `main` changed in `CLAUDE.md`,
`docs/development/cmd-utilities.md` and
`docs/development/repository-map.md` lies outside the lines this layer
edits there, and merged without a conflict. Both times the regeneration
commit was not carried over: I dropped it and regenerated every artifact
on the rebased tree. It changes the same 15 files as before. The tool
snapshots, the tool reference, the llms files and the request inventory,
recorded again on the whole rebased unit suite, change line for line as
they did on the old base. The token footprint with its README block and
the testing reference move by the same amounts from `main`'s new
figures: 225 fewer tokens on each tier's individual surface, and 37 more
test functions and three more test files under `cmd/`, the stack's own
tests.

With the freshness checks on, on this head after the second rebase: `go
test ./... -count=1` passes (301 packages), and again with
`GITLAB_MCP_TEST_SNAPSHOT_PARITY=deferred`. `make analyze` passes 30 of
its 32 steps on the remote runner, and the other two pass locally on the
same tree: markdownlint (step 6, which needs Node) and the copyright and
license headers (step 32, which reads git's file list). Every check the
"Generated artifacts" job of CI runs passes, among them
`check-tool-reference`, `check-llms`, `check-footprint`,
`check-site-stats`, `check-testing-docs`, `check-request-inventory`,
`check-api-live`, `audit-1to1-paths`, `check-action-grants`,
`check-e2e-static`, `check-tenancy` and `check-file-headers`, with
`check-openplugin` and `check-server-json-packages` run locally since
they need the network. `make check-dco` passes for the ten commits of
the stack (the tenth is the second layer's answer to SonarCloud's
`rubydre:S131`, which changes no recorded output). `make test-e2e-http`
(780 tests, 8 skipped because the runner has no Docker) and `make
test-e2e-stdio` (277 tests) pass, the e2e packages compile, and
`test/e2e/gitlab/common` passes `golangci-lint run` and `golangci-lint
fmt --diff`. The site passes `i18n:check`, `facts:check`, `chips:check`,
`llms:check`, `build` and `lint`, and `node scripts/check-doc-links.mjs`
passes.

Against Docker GitLab 19.5.0, the complete CE run (`make test-e2e-ce`
with the skip gate) ran on this stack before the dynamic case of the two
new scenarios was corrected: 1313 tests, and the only failures were
those two dynamic cases, for the wording above. Its skip gate also
failed on four skips, the Bitbucket Cloud and GitHub imports, because
that worktree had no `.env` with their credentials, which the next run
has. The correction touches only that test file. On the stack's head
before the rebases (`25b20c981`), with the skip gate on, the complete CE
run passes 1313 tests (1 skip, which is declared) and the complete EE
run passes 1642 tests (no skips).

I did not run the Docker suites again after the rebases. Since that run,
the server code this stack changes is the same apart from the comment
that names the register row (now 143) and the file headers, and the Ruby
script the second layer's SonarCloud commit splits, which only
`gen_api_live` runs, inside a GitLab it boots. What `main` brought that
those suites exercise is the dependency update of #1564
(`golang.org/x/net` 0.62.0, `google.golang.org/grpc` 1.85.0, `gqlparser`
2.5.64 and `tiktoken-go` 0.10.0 among them, client-go and the go-sdk
unchanged), the Bitbucket Server fixture moved from 9.6 to 10.5 with
basic authentication forced back on, which the import scenarios use, the
copyright and SPDX header in every source file, which is comments, and
the access level and edition tier stack: the access levels each write
offers, cut to what its route accepts, a pending access request no
longer reported as approved, the two checksum filters gone from the
project lists and `new_epic` from a project's notification settings, and
scenarios of its own in `accessrequests_test.go` and
`accesstokens_test.go`. The plaintext listener warning of #1561 is HTTP
mode only, and the e2e suites drive stdio. None of it touches the two
token lists, their packages or the scenarios this stack adds.

## #1517

#1517 is open, and the maintainer has asked for changes before merging
it. This stack leaves to it everything it does or was asked to do: the
offset paging of the merge request diffs in `mr_review.changes_get`,
with the pagination block its output gains and without keyset
continuation, the page walk of the inline comment pre-check under
RQB-013 with its check of the position's SHAs, and the curated text,
request declarations and test moves the review asked for. R-PAGE
classifies `mr_review.changes_get` with the rest, among the 182 actions
offering `page_token` on an offset route, no declaration of it names
that action, and nothing here changes it. Its unused `order_by`, `sort`,
`pagination` and `page_token` are #1530 and the pre-check's
`position_type` is #1531, both after #1517. The two share no
hand-written file: this stack changes
`cmd/audit_1to1/internal/structs/analyze.go`, the `groupserviceaccounts`
and `projectserviceaccounts` packages, R-PAGE in
`cmd/audit_1to1/internal/paths` (`analyze.go`, `pagination*.go`,
`shapes.go`) and the live record's generator, and #1517 changes
`sent_declarations.go` in the same package, the `mr*` packages,
`internal/toolutil/diff_position.go` and `internal/tenancy`, so a rebase
of either is mechanical. Both change generated files:
`internal/tools/testdata/tools_individual.json`,
`tools_meta_compact.json` and `tools_meta_full.json`,
`docs/development/request-inventory.json`,
`docs/development/token-footprint.md` and
`site/src/data/token-footprint.json` with the README token block,
`docs/development/testing/testing.md`, `llms-full.txt` and
`llms-full-individual-tools.txt`. Whichever of #1517 and this stack
lands second regenerates those files on top of the other, together with
the ones only #1517 changes and this stack regenerates unchanged
(`action-requests.json`, the fine-grained table, `tools_meta.json`,
`llms-full-meta-tools.txt` and the `mr-review` tool reference).

---------

Signed-off-by: José M. Requena Plens <mail@jmrp.io>